As is known, service-oriented architecture (SOA) implementations typically involve SOA registries. FIG. 1 is a schematic view showing sample assets in an SOA registry 101. Typically, the SOA registry 101 will be combined with a repository 102 to faun a combined SOA registry/repository 103. Typically, the registry manages metadata only. The repository typically includes files (e.g., WSDL files, XML schema files, etc.). Registered metadata assets are distinguishable from “real world” objects (e.g., the real assets running the web service, etc.), and the former is identified herein as being “assets (reg.).” Relevant building blocks of the SOA, typically referred to as assets (real), may be registered, optionally together with associated metadata (which is the part of the asset (reg.)). The registering of an asset (real) may result in the creation of an asset (reg.), with there normally being at least one asset (reg.) for each asset (real). Relevant metadata may include, for example, name, description, terms of usage, version, and state in the life cycle, etc. Furthermore, the SOA registry may be configured with policies that control addition, change, and/or usage of SOA assets (real and reg.).
Information regarding the interconnection between SOA assets (real) also may be made available in the SOA registry by registering them as interconnections between assets (reg.). If, for example, a business process P implementation 110 makes use of service S 111, and service S 111 is described by a WSDL file 120 that imports XML schema file X 121 that in turn is described by XML schema X, it would be desirable to make available from the SOA registry at least the following information (which may result in many assets (reg.) belonging to the following and/or other asset types (reg.): business process (type), service (type), XML schema (type)) metadata of business process P 110, metadata of service S 111, the WSDL file W 120 for service S 111, and the XML schema specification X 121, together with metadata on X 112. Furthermore, it would be desirable to make available information indicating that P and S are related to each other (via the uses relationship 130), that W is the WSDL of S (via the described by information 131), and that X is in use by W (via the imports information 132). The SOA registry may then derive that P transitively depends on X.
It will be appreciated that in SOA registries, it is quite common to not only register standard SOA assets (real), but to also extend the preconfigured model by environment specific asset types (reg.). These asset types (reg.) may depend on the associated organization, on standards employed in a certain SOA setting, or other factors. Although it sometimes may be possible to extend the model of a SOA registry, the automated registration of corresponding assets (real) currently requires a considerable amount of custom programming. This custom programming may require a potentially deep understanding of the technical requirements and/or associated system architecture of one or more relevant organizations. In addition, when such a component has been programmed, it is not always easy to share it between multiple installations of a SOA registry. Typically, an installation activity is needed that might even cause a temporary unavailability of the registry. This temporary downtime might come at an inopportune time or may be required in implementations where “continuous uptime” is required.
Indeed, while there typically is a common understanding of SOA principles among companies that implement their IT according to these principles, the specific implementation of an SOA very frequently varies between the implementers, and the principles of governance of such an environment can vary even more. As a consequence, in one company implementing an SOA, a certain type of assets might be of high importance, while in other companies such assets are not even present. Consider, for example, Company A that makes use of the Service Component Architecture (SCA) standard for the management of its software. For this company, the management of SCA composites might be important. Typically, such assets of interest include a whole group of assets of various types. In the SCA example, an SCA composite includes SCA components, services, implementations, wires, etc., that all may need to be reflected when an SCA composite is registered in the SOA registry. By contrast, another Company B might not make use of the SCA standard. In such a situation, SCA composites may be of no value for company B.
As a consequence of these differences in SOA implementations, the producers of SOA registries cannot always foresee all asset types that might be relevant in a certain company's SOA implementation. While there are some asset types that are most probably relevant in all or most SOA implementations (e.g., “Service” asset types), many other asset types might be very organization specific.
To address this issue, SOA registries typically have an open type model, allowing customers to define new asset types. After definition of an asset type (reg.), assets (reg.) of this type typically can be entered via a user interface. However, in many cases, an automatic registration based on a description available in another format would be preferable. For example, for a company dealing with SCA composites, manually typing all details of the SCA composite (that oftentimes include many sub-parts) would be cumbersome. There is, however, an XML file for each composite that contains all basic information about the composite. The SOA registry could read this XML file and derive the necessary information for registration. This process is called “import.”
FIG. 2 shows a current approach for implementing a specific import functionality. Currently, someone (and typically the vendor of the SOA registry) will program a dedicated plug-in 202 for each specific import functionality for the SOA registry that reads the external descriptions 201 of the asset type(s) 203 to be imported. For instance, separate dedicated plug-ins 202 may be provided for SCA composites, web applications, database configurations, etc. It is noted that these external descriptions 201 may include several files. The plug-ins 202, in turn, may register the corresponding assets 204, and optionally store corresponding files 205 in the SOA repository. The programmer may then provide the plug-in(s) to the operator of the SOA registry. It will be appreciated that different specific import functionality implementations may generate assets of the same asset type, e.g., as shown in FIG. 2.
The operator of the SOA registry typically has to install the plug-in(s), which typically requires at least a restart of the registry, and very often also requires access rights on the server where the SOA registry is installed. The access rights needed are often those of an administrator of the server, which is typically different from the administrator of the SOA registry. When the asset type's (reg.) data model or the external format describing the asset change, the SOA registry vendor most likely has to change the relevant plug-in(s) and provide it/them anew to the operator. Once a certain import functionality is installed, it typically is usable by all users. However, it is believed that there are no techniques for restricting import of a specific kind of assets to certain users in current solutions.
Thus, it will be appreciated by those skilled in the art that there is a need in the art for techniques that address one of more of the above-described and/or other issues.
One aspect of certain example embodiments of this invention relates to using the registry's own mechanisms to introduce new importing capabilities.
Another aspect of certain example embodiments of this invention relates to making it easier to adapt the import functionality to changes in the source assets or in the registry's model.
Another aspect of certain example embodiments of this invention relates to restricting the example importing techniques so that they are made available for certain users only. Such restrictions can be put in place specifically for a certain import functionality in certain example embodiments. In addition, or in the alternative, the modification and creation of import functionality can be restricted to certain users.
Still another aspect of certain example embodiments of this invention relates to modeling the import specifications as assets (reg.) that are stored in the SOA registry itself and interpreted by a generic import module a definition regarding how to retrieve information from external specification file(s).
In certain example embodiments, a computer system includes processing resources including at least one processor and at least one memory. At least one non-transitory computer readable storage medium is accessible by the processing resources and includes: a repository configured to store a plurality of files relating to assets (real), and a registry containing metadata and other information about these assets (real), including at least one asset (reg.) per asset (real) and with each asset (reg.) having an asset type (reg.). A generic import module is configured to (a) receive as input one or more import specifications, with each said import specification defining how information from an external specification file of an asset type is to be extracted to create one or more assets (reg.) of one or more corresponding target asset types (reg.), (b) generate one or more assets (reg.) of one or more target asset types (reg.) based on a corresponding import specification, and (c) register, in the registry, the generated one or more assets (reg.) of the one or more target asset types (reg.).
In certain example embodiments, there is provided a method of importing assets (reg.) having one or more source asset types (reg.) together with relevant documents (e.g., files) into a service-oriented architecture (SOA) registry and/or repository. The SOA repository and the SOA registry are stored in a non-transitory computer readable storage medium of an SOA computer system comprising at least one computer having at least one processor in operable communication with the SOA repository and the SOA registry. A generic import module is invoked, via the at least one processor, in response to input identifying an import functionality and the target SOA registry, and either (a) input specifying one or more external specification files describing the one or more assets to be registered, or (b) an automatic derivation of the one or more external specification files describing the one or more assets to be registered based on a relationship between the one or more external specification files and the identified import functionality. One or more import specifications is/are retrieved. An extraction algorithm specified by the one or more retrieved import specifications is run on the external specification files to be registered to create one or more target assets (reg.) having one or more target asset types (reg.). The one or more target assets (reg.) having one or more target asset types (reg.) are stored or registered in the SOA registry.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.